This part of IEC 80001, which is a technical report, gives guidance and practical techniques for RESPONSIBLE ORGANIZATIONS, MEDICAL DEVICE manufacturers and providers of other information technology in the application of IEC 80001-1:2010 for the RISK MANAGEMENT of DISTRIBUTED ALARM SYSTEMS. This technical report applies to the transmission of ALARM CONDITIONS between SOURCES, INTEGRATOR and COMMUNICATORS where at least one SOURCE is a MEDICAL DEVICE and at least one communication path utilizes a MEDICAL IT-NETWORK. This technical report provides recommendations for the integration, communication of responses and REDIRECTION (to another OPERATOR) of ALARM CONDITIONS from one or more SOURCES to ensure SAFETY and EFFECTIVENESS. DATA AND SYSTEMS SECURITY is an important consideration for the RISK MANAGEMENT of DISTRIBUTED ALARM SYSTEMS. Figure 2 illustrates the functions of a MEDICAL IT-NETWORK incorporating SOURCES, an INTEGRATOR and COMMUNICATORS to distribute ALARM CONDITIONS. NOTE This is a functional diagram and does not imply that these functions are in separate components. It is possible for functionality to be provided in one or more components. The following is a typical chain of events. An event is detected by a SOURCE that initiates an ALARM CONDITION. The SOURCE sends the ALARM CONDITION to the INTEGRATOR. Based on the RESPONSIBLE ORGANIZATION-established assignment protocol, the INTEGRATOR directs the ALARM CONDITION to the assigned COMMUNICATOR. The COMMUNICATOR generates the appropriate ALARM SIGNALS. The INTEGRATOR now waits for an OPERATOR response from the COMMUNICATOR or for the SOURCE to indicate that the ALARM CONDITION no longer exists. If the COMMUNICATOR is capable of accepting a response and the OPERATOR responds, the OPERATOR indicates that it either accepts or rejects responsibility for the ALARM CONDITION. If the OPERATOR rejects the responsibility, the INTEGRATOR redirects the ALARM CONDITION to a different COMMUNICATOR (i.e. a different OPERATOR) and might also escalate the priority of the ALARM CONDITION. Eventually an OPERATOR accepts responsibility for the ALARM CONDITION. When an OPERATOR has taken appropriate action, the ALARM CONDITION subsequently ends. Alternately, the ALARM CONDITION could end without OPERATOR action in which case when the SOURCE notifies the INTEGRATOR that the ALARM CONDITION is no longer present, the INTEGRATOR instructs the COMMUNICATOR to stop generating ALARM SIGNALS. Should an ALARM CONDITION remain uncorrected for an extended period of time, the ALARM SYSTEM should cause the ESCALATION of the ALARM CONDITION, notify additional OPERATORS, etc. EXAMPLE A pulse oximeter detects a low SpO2 level in the PATIENT, initiates an ALARM CONDITION and sends that ALARM CONDITION to the INTEGRATOR via a MEDICAL IT-NETWORK. The INTEGRATOR then directs that ALARM CONDITION to the COMMUNICATOR that is mapped to the clinical OPERATOR assigned to the PATIENT via a MEDICAL IT-NETWORK. OPERATOR A responds by rejecting responsibility for the ALARM CONDITION. The COMMUNICATOR sends this response information back to the INTEGRATOR, which then redirects the ALARM CONDITION to the COMMUNICATOR of clinical OPERATOR B. OPERATOR B then accepts responsibility for the ALARM CONDITION. The COMMUNICATOR sends this response information back to the INTEGRATOR, which then sends it back to the SOURCE causing an ALARM SIGNAL inactivation state (e.g. AUDIO PAUSED) to be generated. OPERATOR B adjusts the oxygen concentration in the gas going to the PATIENT and the ALARM CONDITION ceases (e.g. the event ends).